This invention relates to the field of processing machine runtime environments. In particular, this invention relates to a method of splitting a processing machine runtime between a host system and a target system for conserving resources at the target system.
Currently, the state of the art virtual machine is the Java™ virtual machine (JVM) from Sun Microsystems, Inc. (Sun). At the centre of Sun Microsystems Java™ technology is their Java™ virtual machine code, or byte code, as currently specified by the class file format in chapter 4 of the second edition of The Java™ Virtual Machine Specification by Tim Lindholm and Frank Yellin, Addison-Wesley Pub Co; ISBN: 0201432943.
Class file byte code co-operates with Sun's Java™ Runtime Environment (JRE) on the Solaris™, Win32, Linux™, Mac, and possibly other platforms. Typically, source code written in the Java™ programming language, is compiled into virtual machine byte code respecting the class file format by using a Java™ compiler, such as “javac”, and then executed using the JRE or a compatible runtime environment and processing machine.
In reference to FIG. 1, d layered JRE architecture block diagram illustrates several aspects of the Sun technique. Various mechanisms (100A and 100B) provide program software (110A and 110B) byte code class files. For instance, a compiler 100A compiles software 110A into byte code class files. Alternatively, a web browser may use a software “plugin” 110B to download software 100B byte code class files.
Byte code in a class file usually references several other classes, each of which has a class file. For that reason, standard package 120 class files are provided as a shared software resource to be re-used by instances of software (110A and 110B). The JVM 140 obtains class files and executes software (110A and 110B) and standard package class files 120.
Also shown are the various systems 130 on top of which the JRE 142 operates. The standard packages in a runtime define a particular runtime platform specified in an application programmer's interface (API).
The Java™ 2 Standard Edition (J2SE) is a Sun reference platform API. They also provide a reference implementation comprising a JRE configured with a set of standard packages running on the JVM. Application developers can write applications in the Java™ programming language referring to the J2SE standard package classes and may expect to have their applications run on J2SE compliant runtime systems. Other platforms exist which are usually defined by comparison to the J2SE. For instance, a superset of J2SE, the Java™ 2 Enterprise Edition (J2EE) adds further features. Of particular interest is a subset of J2SE, the Java™ 2 Micro Edition (J2ME).
Although the J2SE platform may be well suited to operate on systems such as those illustrated by the Solaris™, Win32, Mac, Linux™, and other blocks 130 of FIG. 1, J2SE may not be well suited for operating on many devices. For instance, the class files of the standard J2SE packages may presently consume well over 16 Megabytes of disk space, which may exceed the storage capacity of many devices.
To address this problem, Sun introduced the Java™ 2 Micro Edition (J2ME) platform, additional virtual machines, and associated device configurations.
The Connected Limited Device Configuration (CLDC) and K Virtual Machine (KVM) address small consumer devices that you hold in your hand, with 128K to 512K of memory, and when used with the Mobile Information Device Profile (MIDP) may provide an application environment for devices such as cell phones and two-way pagers.
The Connected Device Configuration (CDC) and C Virtual Machine (CVM) address emerging, next-generation consumer devices with 2 MB or more of memory, and when used with the Foundation Profile (FP) may provide an application environment for next-generation consumer devices.
An advantage of J2ME is that when it is used with the aforementioned CLDC or CDC configurations, fewer standard class packages are stored on many devices as compared to J2SE. Therefore J2ME may take up less space on a device at the expense of not supporting all of the features of J2SE.
Although Java™ runtime technology may be available for different systems and devices, and although the J2ME platform addresses the limited storage space problem of devices by removing functionality, J2ME may not be considered an adequate solution since it may not address the efficiency of a device runtime implementation. Thus, there is a need for a runtime that is optimized for a target device (as well as other needs).
In order to better understand the present invention, the following information regarding Java runtime technology is provided. According to Lindholm et al., in section §2.17.1 of the Sun JVM spec: “The Java virtual machine starts execution by invoking the method main of some specified class and passing it a single argument, which is an array of strings. This causes the specified class to be loaded (§2.17.2), linked (§2.17.3) to other types that it uses, and initialized (§2.17.4)”. Therefore by specifying the name of a “main” class when starting the JVM 140 of FIG. 1, a class file will be loaded and execution of byte code instructions will begin at the static main entry point of that class file. Furthermore, referenced types, such as classes, used by the “main” class will be linked and initialized. Depending on the use of other classes by the “main” class file, significant runtime resources will be consumed in order to load and link used class files.
Java™ runtime technology requires that the runtime system load and link all required class files each time a “main” class is specified for execution, which may cause the precipitous consumption of resources on a target system such as a device.
A typical Java™ application has at least one “main” class file containing a static main entry point, as well as possibly having several supporting class files.
The following example Java™ program listing is considered next:
public class Hello {public static void main(String[ ] a) {System.out.println(“Hello!”);Bye.bye(a);}}public class Bye {public static void bye(String[ ] a) {System.out.println(“Bye!”);}}
The above listing provides source code for two classes, Hello and Bye, each of which can be compiled into class file format in a way which is known to a person skilled in the art, such as by placing the source for each class in a Hello.java file and a Bye.java file and using the command “javac Hello.java Bye.java” to obtain a Hello.class file and Bye.class file.
The Hello class provides a static main entry point and is therefore suitable to be specified as a “main” class when starting the JVM 140.
In reference to FIG. 2, the linking technique of the runtime of FIG. 1 is considered in reference to the above example “Hello” program. A plurality of class files 200 is available to the virtual machine 140 (of FIG. 1). Each class file has symbolic information that is used by the virtual machine 140 to resolve references to other used class files.
Typically, the Hello.class file 210A is loaded at 220A first as it is specified when starting the JVM 140. The JVM 140 then proceeds to execute byte code instructions at the main entry point of the loaded class 220A. Since the Hello class 220A uses several standard package classes, the class files for the used classes will be loaded and linked to the Hello class 220A. The Object.class file 210B will be loaded at 220B and linked 230B to the 210A Hello class. Similarly, the String.class file 210C, System.class file 210D, and other class files 210 used by the Hello class are loaded at 220C, 220D, 220 and linked at 230C, 230D, and 230. The Hello class also uses the Bye class (a supporting class which is not a standard package class) so the Bye.class file 210E will be loaded at 220E and linked at 230E.
Although not expressly shown in the drawings, each time a class file 210 is loaded at 220 and linked at 230, any class files the loaded class 220 uses might also be loaded and linked. For instance, in the case of the loaded supporting Bye class 220E, it uses many of the same classes as the Hello class 210A. Depending on when the Bye class 220E is loaded and linked 230E, the Bye class 220E may not have to load the class files 210 that are common with classes also used and loaded by the Hello class. However, all classes used by Bye 220A will ultimately have to be linked to Bye as well for Hello to be able to use the supporting Bye class. The situation is similar with standard package classes.
Traditional class file 210 loading (at 220) and linking (at 230) consume significant runtime resources and may slow down the execution of a “main” program 220A when loading and linking of class files is triggered by the specification of a command to execute a program, as will be discussed further next in reference to FIGS. 3A and 3B.
With reference to FIGS. 3A and 3B, a flowchart further illustrating the runtime linking technique of FIG. 2, particularly illustrating optional late resolution, is discussed. The “main” class is loaded at 310 from class storage 200, such as a hard drive or a network. The class is verified and prepared at 315. If late resolution is not used as determined at 320, then all used classes are linked and loaded at 325. Regardless of whether late resolution is used at 320 or not, the “main” class is initialized at 330.
Instructions from the main entry point are fetched at 335. If the fetched instruction does not involve an unresolved reference as determined at 340, the fetched instruction is executed at 345. However if the fetched instruction involves an unresolved identifier reference as determined at 340, such as a class reference to a class that has not yet been loaded, then if late resolution is not used as determined at 350, an exception is thrown in the runtime. If late resolution is used as determined at 350, and if the referenced class cannot be loaded at 355, an exception is thrown in the runtime. However, if late resolution is used as determined at 350, and the referenced class can be loaded, the referenced class is loaded and the reference is resolved at 360 prior to executing the instruction at 345. If there are more instructions to execute as determined at 365, then the next instruction is fetched at 335, or else the virtual machine ends.
If late resolution were used, then several class files would have been loaded and linked at 360 during execution of the main program byte code. Alternatively, if late resolution were not used, several class files would have been loaded and linked at 325 prior to executing the main program byte code, after specifying the “main” class file to the JVM 140. In either case, a precipitous consumption of resources for loading and linking may ensue between the time the main program was specified for execution by the JVM 140 in the runtime and the time when the main program either terminated or threw an exception.
Therefore, even by eliminating late resolution, there is a potential risk for a precipitous consumption of resources for loading and linking class files in execution triggered linking and loading.